Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/program/progem.arc/gem6.asc

Text File | 1987-10-10 | 21KB | 434 lines

                        *PROFESSIONAL GEM*
                           by Tim Oren
                  Column #6 - Raster operations

                        SEASONS GREETINGS!

     This is the Yuletide installment of ST PRO GEM, devoted to
explaining the raster, or "bit-blit" portion of the Atari ST's VDI
functions.

     Please note that this is NOT an attempt to show how to write
directly to the video memory, although you will be able to deduce a
great deal from the discussion.

     As usual, there is a download with this column.  You will find
it in ATARI16 (PCS-58) in DL3 under the name of GEMCL6.C.

                          DEFINING TERMS

     To understand VDI raster operations, you need  to understand the
jargon used to describe them.  (Many programmers will be tempted to
skip this section and go directly to the code.  Please don't do it
this time:  Learning the jargon is the larger half of understanding
the raster operations!)

     In VDI terms a raster area is simply a chunk of contiguous words
of memory, defining a bit image.  This chunk is called a "form".  A
form  may reside in the ST's video map area or it may be in the data
area of  your application.  Forms are roughly analogous to "blits" or
"sprites"  on other systems.  (Note, however, that there is no sprite
hardware on the ST.)

     Unlike other systems, there is NO predefined organization of the
raster form.  Instead, you determine the internal layout of the form
with an auxiliary data structure called the MFDB, or Memory Form
Definition Block.  Before going into the details of the MFDB, we need
to look at the various format options.  Their distinguishing features
are monochrome vs. color, standard vs. device-specific and even-word
vs. fringed.

                       MONOCHROME VS. COLOR

     Although these terms are standard, it might be better to say
"single-color vs. multi-color".  What we are actually defining is the
number of bits which correspond to each dot, or pixel, on the screen.
In the ST, there are three possible answers. The high-resolution mode
has one bit per pixel, because there is only one "color": white.

     In the medium resolution color mode, there are four possible
colors for each pixel.  Therefore, it takes two bits to represent
each dot on the screen.  (The actual colors which appear are
determined by  the settings of the ST's pallette registers.)

     In the low resolution color mode, sixteen colors are generated,
requiring four bits per pixel.  Notice that as the number of bits per
pixel has been doubled for each mode, so the number of pixels on the
screen has been halved: 640 by 400 for monochrome, 640 by 200 for
medium-res, and 320 by 200 by low-res.  In this way the ST always
uses  the same amount of video RAM: 32K.

     Now we have determined how many bits are needed for each pixel,
but not how they are laid out within the form.  To find this out, we
have  to see whether the form is device-dependent or not.

               STANDARD VS. DEVICE-SPECIFIC FORMAT

     The standard raster form format is a constant layout which is
the same for all GEM systems.  A device-specific form is one which is
stored in the internal format of a particular GEM system.  Just as
the ST has three different screen modes, so it has three different
device-specific form formats.  We will look at standard form first,
then the ST-specific forms.

     First, it's reasonable to ask why a standard format is used. Its
main function is to establish a portability method between various
GEM systems.  For instance, an icon created in standard format on an
IBM PC GEM setup can be moved to the ST, or a GEM Paint picture from
an AT&T 6300 could be loaded into the ST version of Paint.

     The standard format has some uses even if you only work with the
ST, because it gives a method of moving your application's icons and
images amongst the three different screen modes.  To be sure,  there
are limits to this.  Since there are different numbers of pixels  in
the different modes, an icon built in the high-resolution mode will
appear twice as large in low-res mode, and would appear oblong in
medium-res.  (You can see this effect in the ST Desktop's icons.)
Also,  colors defined in the lower resolutions will be useless in
monochrome.

     The standard monochrome format uses a one-bit to represent
black, and uses a zero for white.  It is assumed that the form begins
at the  upper left of the raster area, and is written a word at a
time left to right on each row, with the rows being output top to
bottom.  Within each word, the most significant bit is the left-most
on the screen.

     The standard color form uses a storage method called "color
planes". The high-order bits for all of the pixels are stored just as
for monochrome, followed by the next-lowest bit in another contiguous
block, and so on until all of the necessary color bits have been
stored.

     For example, on a 16-color system, there would be four different
planes.  The color of the upper-leftmost bit in the form would be
determined by concatenating the high-order bit in the first word of
each plane of the form.

     The system dependent form for the ST's monochrome mode is very
simple: it is identical to the standard form!  This occurs because
the  ST uses a "reverse-video" setup in monochrome mode, with the
background  set to white.

     The video organization of the ST's color modes is more
complicated. It uses an "interleaved plane" system to store the bits
which make up a pixel.  In the low-resolution mode, every four words
define the values of 16 pixels.  The high-order bits of the four
words are merged to form the left-most pixel, followed by the next
lower bit of each word, and so on.  This method is called
interleaving because the usually separate color planes described
above have been shuffled together in memory.

     The organization of the ST's medium-resolution mode is similar
to low-res, except the only two words are taken at a time.  These are
merged to create the two bits needed to address four colors.

     You should note that the actual color produced by a particular
pixel value is NOT fixed.  The ST uses a color remapping system
called a palette.  The pixel value in memory is used to address a
hardware  register in the palette which contains the actual RGB
levels to be sent to the display.  Programs may set the palette
registers with  BIOS calls, or the user may alter its settings with
the Control Panel desk accessory.  Generally, palette zero
(background) is left as white, and the highest numbered palette is
black.

                      EVEN-WORD VS. FRINGES

     A form always begins on a word boundary, and is always stored
with an integral number of words per row.  However,  it is possible
to use only a portion of the final word.  This partial word is called
a "fringe".  If, for instance, you had a form 40 pixels wide,  it
would be stored with four words per row: three whole words, and one
word with the eight pixel fringe in its upper byte.

                              MFDBs

     Now we can intelligently define the elements of the MFDB.  Its
exact C structure definition will be found in the download. The
fd_nplanes entry determines the color scheme: a value of one is
monochrome, more than one denotes a color form.  If fd_stand is zero,
then the form is device-specific, otherwise it is in standard format.

     The fd_w and fd_h fields contain the pixel width and height of
the form respectively.  Fd_wdwidth is the width of a row in words.
If fd_w is not exactly equal to sixteen times fd_wdwidth, then the
form has a fringe.

     Finally, fd_addr is the 32-bit memory address of the form
itself. Zero is a special value for fd_addr.  It denotes that this
MFDB is for the video memory itself.  In this case, the VDI
substitutes the actual address of the screen, and it ignores ALL of
the other parameters. They are replaced with the size of the whole
screen and number of planes in the current mode, and the form is (of
course) in device-specific format.

     This implies that any MFDB which points at the screen can only
address the entire screen.  This is not a problem, however, since t